(19) 



J 



Europaisches Patentamt 
European Patent Offi e 
Office europeen des brevets 




(12) 



(11) EP 0 895 145 A1 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 


(51) intci.6: G05B 19/05, H04L 12/46 


03.02.1999 Bulletin 1999/05 


(21) Application number: 98305519.5 




(22) Date of filing: 10.07.1998 




(84) Designated Contracting States: 


(72) Inventor: Eidson, John C. 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Palo Atto, California 94303 (US) 


MC NL PT SE 




Designated Extension States: 


(74) Representative: Jehan, Robert et al 


AL LT LV MK RO SI 


Williams, Powell & Associates, 




4 St Paul's Churchyard 


(30) Prbrity: 01.08.1997 US 904364 


London EC4IM 8AY (GB) 


(71) Applicant: Hewlett-Packard Company 




Palo Atto, California 94304 (US) 





(54) Process control device 

(57) A method and apparatus provides a standard 
interface (14) to process control devices (20-22) which 
are adapted to differing field-bus protocols (18). The 
method and apparatus enable integration of process 



control devices (20-22) adapted to differing field-bus 
protocols (18) while avoiding the use of protocol gate- 
ways which would otherwise greatly complicate the task 
of developing process control application programs. 
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Description 

[0001] The pres nt invention pertains to providing a standard interface to process control devices which are adapted 
to differing f1 Id-bus protocols. 

5 [0002] Industrial process control syst ms typically nriak use of a variety of devic s such as temp ratur sensors, 
pressure sensors, and actuators. Such devices are hereinafter referred to as process control devices. In addition, 
industrial process control systems commonly make use of field-level control buses which are specialized for the process 
control environment. Such specialized buses include Profi-bus, LonTalk, SDS. and DevtceNet buses to name a few. 
Communication buses specialized tor the processes control environment are hereinafter referred to as field-buses. 

10 [0003] Typically, one or more centralized controllers in such an industrial process control system are used to manage 
the process control devices. Such a centralized controller may be referred to as a programmable logic controller (PLC). 
A PLC is usually connected to one or more process control devices via one of the differing types of field-buses. A PLC 
typically includes a processor that executes a set of application code for conrvnunicating with and controlling the cor- 
responding process control devices. 

IS [0004] Typically, the application code in a PLC and the process control devices managed by the PLC are adapted 
to the communication protocol of the particular fieW-bus being employed. For example, a PLC that connects to process 
control devices via a Profi-bus typically executes applrcatbn code that is adapted to the Profi-bus communication 
protocol. In addition, the process control devices connected to the Profi-bus are usually adapted to the communication 
protocol of the Profi-bus. Similarly, PLCs and process control devices connected together via an SDS bus are typically 

20 adapted to the SDS bus protocol. 

[0005] It is often desirable to integrate differing process control subsystems into a larger system. Such a situation 
may arise when two process control plants that use differing field-buses are merged. For example, one plant may have 
an existing Profi-bus based process control system while the other may have an existing SDS based process control 
system. It is usually desirable to provide a mechanism for communicatk^n between the two differing systems rather 

25 than perform an expensive retrofit of process control devices. 

[0006] One prk>r solution for providing communication between systems having differing protocols can be found in 
the field of computer networks in which protocol gateways are commonly used to translate between differing networic 
protocols. For example, protocol gateways are comnrKxily used to provide protocol translation between Ethernet net- 
works and token-ring networks. Such protocol gateways are typically well suited for communication between computer 

30 networks which merely exchange files and c^ta. 

[0007] In contrast, a typical application program running on a PLC in a process control system perfornDS real-time 
sampling and control of sensors and actuators in a precise manner in which many dependancies among the process 
control devices can exist. The specialized protocols of field-buses have evolved to meet these specialized needs. As 
a consequence, a protocol gateway between differing fiekJ-buses would likely be very complex and probably coukJ not 

35 provide complete translatbn between protocols. Application programs in a system that included such protocol gateways 
would probably have to handle at least a portbn of all of the field-bus protocols in use in the control system regardless 
of the existence of protocol gateways. 

[0008] For example, an application program for a system that included a Profi-bus connected to an SDS bus through 
a protocol gateway would typically have to handle both Profi-bus and SDS protocols to some extent. Moreover, if the 

40 system were to include a LonTalk bus with a corresponding protocol gateway then the application program would 
probably have to handle all three protocols to some extent. The complexities worsen as more and more differing types 
of field buses are integrated into the system through protocol gateways. Unfortunately, such complexities typically 
increase the time and cost of devetoping applicatk>n programs in the system and increase the difficulty and cost of 
maintaining the process control system. 

45 [0009] In addition, providers of process control devices are confronted with the task of producing devices that are 
capable of communlcatk>n over each of the wide variety of field-bus types in use. For example, the manufacturer of a 
particular temperature sensor designed for the SDS bus would usually devek>p pemnutations of the sensor adapted 
for the Profi-Bus and SDS buses if they wish to sell into industrial environments that use those types field-buses. 
Unfortunately, such design permutations typk:ally increases manufacturing and development costs and maintenance 

50 costs of such process control devices. 

[0010] The present invention seeks to provkie an interface to a process control device. 

[001 1 ] According to an aspect of the present invention there is provded apparatus for providing a standard interface 
to a process control device as specified in claim 1 . 

[0012] According to another aspect of the present inventbn there is provided a process control system as specified 
55 in claim 8. 

[0013] The prefen-ed method and apparatus provides a standard intertac to process control devices which are 
adapted to differing field-bus protocols. It enables integration of process control devices adapted to differing fieki-bus 
protocols whil avoiding the us of protocol gateways which wouW otherwise greatly comptk:ate the task of devek>ping 
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process ccxitrol application programs. In addition, it enables process syst m design rs to integrate any type of process 
contr I device into a system regardless f the type of field-bus for which the proc ss control device is adapted. It can 
also provide nrianufacturers of process control d vices with a larger potential customer base without having to provide 
permutations of their process control devices adapted to th wide range of field^us protocols. 
5 [0014] In an mbodim nt, a standard int rf ace is provided by a mapper which includes a means for obtaining a s t 
of information pertaining to the process control device wherein the information describes the process control device 
according to a predetermined device^riented protocol that corresponds to the standard interface. The mapper further 
includes a means for enabling a process control application to access the information using the predetermined device- 
oriented protocol. 

10 [0015] An embodiment of the present invention is described below, by way of example only, with reference to the 
accompanying drawings, in which: 

Figure 1 illustrates a system that provides an application controller with a standard interface to a set of process 
control devices that are adapted to the specialized protocol of a field-bus; 

IS 

Figure 2 illustrates a mapper which includes a niapping processor, a device-oriented interface, and a field-bus 
interface; 



Figure 3 illustrates an exanrrple process control system that enables process control applications executing on a 
20 set of application controllers to access process control device adapted to differing field-bus protocols through a 

standard interface. 



[0016] Figure 1 illustrates a control system 10 including a mapper 16 and an application controller 12. The nnapper 
16 provides a standard interface having a device-oriented protocol 14 to a set of process control devices 20-22 that 

25 are adapted to a specialized protocol of a field-bus 18. 

[0017] The process control devices 20-22 each represent a process control device which is designed specifically for 
communication according to the predetermined protocol of the field-bus 18. For example, any one or more of the 
process control devices 20-22 may be a temperature sensor, a pressure sensor, or an actuator. In addition, any one 
or more of the process control devices 20-22 may provide multiple process control functions. 

30 [0018] The field-bus 1 8 represents any one of a number of field buses suitable for communication among process 
control devices. For example, the fteld-bus 1 8 may be embodied as a Profi-bus, a LonTalk, an SDS, a DeviceNet, an 
SDS bus, or any equivalent bus. If the field-bus 18 is a Profi-bus, for example, then the process control devices 20-22 
are each adapted to the Profi-bus communication protocol. Similarly, if the filed-bus 18 is an SDS bus, then the process 
control devices 20-22 are each adapted to the SDS protocol. 

35 [001 9] The application controller 1 2 includes a processor that executes application code for communication with and 
control of the process control devices 20-22. The application code executed by the application controller 12 is written 
under the assumption that the process control devices 20-22 conform to the device-oriented protocol 1 4. As a conse- 
quence, the application controller 1 2 and its application code can be designed and developed without regard to whether 
the field-bus 18 is a Profi-bus, or an SDS bus. etc. 

40 [0020] The device-oriented protocol 14 represents any standard device-oriented protocol that provides for multiple 
device channels and that defines a protocol that enables the application controller 12 to discover information about 
attached devices. One standard interface suitable for use as the device-oriented protocol 14 is the proposed IEEE 
1451 .2 standard. The IEEE 1451 .2 proposed standard specifies multiple channels for obtaining device variables and 
defines a format of information pertaining to each attached device. The information pertaining to a particular attached 

45 device describes the type of device, the data rate, units of measure and special triggering requirements, etc. 

[0021] The mapper 16 communicates with the process control devices 20-22 via the field-bus 18 using the prede- 
termined protocol associated with the field-bus 18. The mapper 16 provides functionality that enables the application 
controller 12 to communicate with the process control devices 20-22 using the device-oriented protocol 14 such that 
it appears to the application controller 1 2 that the process control devices 20-22 are devices that conform to the device- 

50 oriented protocol 14. In addition, the nnapper 16 builds a set of information pertaining to each of the process control 
devices 20-22 according to the requirements of the device-oriented protocol 14, which in one emlxxiiment is specified 
in the IEEE 1451.2 proposed standard. 

[0022] Figure 2 illustrates the mapper 16. The mapper 16 includes a mapping processor 30. a device-oriented in- 
terface 34, and a field-bus interface 36. The mapping processor 30 maintains configuration information in a device- 
's oriented interface database 32. 

[0023] The device-oriented interface 34 enables th mapping processor 30 to communicate with the application 
controller 12 according to th devic -oriented protocol 14. The device-oriented interface 34 ir^ludes specialized cir- 
cuitry and control lements according to the typ of devic -oriented protocol. In one embodiment, the device-oriented 
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interface includes circuitry and control elements suitable to the IEEE 1451.2 interface standard. 
[0Q24] The field-bus tnterfac 38 enables th mapping processor 30 to communicat withth process control d vices 
20-22 via the field-bus 1 8 according to the predetermined protocol of th field-bus 1 8. The field-bus interface 38 includes 
specialized circuitry and control elements for th field-bus 1 8. For xampi , if the field-bus 1 8 is an SDS bus, then th 
s field-bus interfac 36 includes circuitry and control elem nts for connecting to an SDS bus and for communicating with 
the devices 20-22 using the SDS protocol. 

[0025] The mapping processor 30 uses the field-bus interface 38 to detect devices connected to the field-bus 1 8, i. 
a. the devices 20-22 and any other devices detectable according to the protocol of the field bus 18. The method used 
by the mapping processor 30 to detect devices connected to the field-bus 18 depends on the predetermined protocol 
10 of the field-bus 18. At the very minimum, each type of field bus protocol provides a method that enables the detenmi- 
nation of a device identifier for each connected device. The mapping processor 30 may obtain the device identifiers, 
tor example, by transferring polling or query messages or packets over the field-bus 1 8 through the field-bus interface 
36. The process control devices 20-22 each respond with their respective device identifiers. 

[0026] The mapping processor 30 builds a set of configuratbn information into the device-oriented interface database 
15 32. The configuration information which the mapping processor 30 builds into the device-oriented interface database 
32 includes information that describes the process control devices 20-22 in terms of the device-oriented protocol 14. 
As a consequence, the fomnat of the configuration information in the device-oriented interface database 32 depends 
of the particular device-oriented protocol being used. In the case of the IEEE 1451 .2 standard, the configuration infor- 
mation in the device-oriented interface database 32 includes device-specific information and interface-specific infor- 
20 nnation. 

[0027] The device-specific intonmation in the database 32 includes a set of device-specific information for each of 
the process control devices 20-22 detected by the nnapping processor 30. The device^pecific information for a par- 
ticular process control device includes information such as the number of variables associated with the process control 
device, the update rate of the process control device, units of measure, triggering requirements, and calibration infor- 
ms nrtation. The number of variables associated with a process control device depends upon the particular device. In 
general, each variable associated with a process control device maps to a channel of the device-oriented protocol 14. 
For example, a particular process control device may measure both temperature and pressure. In such a case, the 
process control device would require two channels of the device-oriented protocol 14. 

[0028] The interface-specific infonmation in the device-oriented interface database 32 is configuration information 
30 associated with the device-oriented protocol 1 4. It includes infonmation such as the number of channels of the device- 
oriented protocol 14 used up by the devices connected to the field-bus IB, as well as the data rate used for transfers 
between the application controller 1 2 and the mapper 16. For example, if the device identifiers returned by the process 
control devices 20-22 indicate a single variable temperature sensor and a single variable pressure sensor, respectively, 
then the mapping processor 30 maps these to variables to the first two channels of the device-oriented interface 34. 
35 The mapping processor 30 maps the first two channels by writing the interface-specific configuration information in the 
device-oriented interface datattase 32 with appropriate values that indicate the first two channels are occupied by 
device variables. 

[0029] In one embodiment, the necessary infomnation for building the information into the device-oriented interface 
database 32 is contained within the process control devices 20-22. The mapping processor 30 obtains the information 
40 directly from the process control devices 20-22 via the field-bus 18. For example, the mapping processor 30 may 
directly query the process control device 20 to obtain information such as device type, units of measure, data rate, 
triggering requirements, etc. 

[0030] In the alternative embodiment, the mapping processor 30 obtains the device-specific information for building 
the database 32 from a device dictionary 38. The device dictionary 38 contains a set of predetermined device-specific 

4S infonmation which is tailored in terms of the device-oriented protocol 14 for each particular process control device 
supported by the nnapper 16. The device dictionary 38 may be indexed by the device identifier for a particular process 
control device. For example, assume the process control device 20 returns a device identifier of "1.7.3.1 " in response 
to a query by the mapping processor 30. The n^apping processor 30 converts this device identifier into an index for 
accessing device-specific information from the device dictionary 38. The mapping processor 30 then reads the device- 

50 specific information from the device dictionary 38 and writes it to appropriate entries in the device-oriented interface 
database 32. 

[0031] The device dictionary 38 may be embodied in a static or non-volatile memory. However the annount of infor- 
mation that must be stored in the device dictionary 38 can be quite large depending on the number of possible permu- 
tations of process control devices supported by the mapper 16 and the amount of informatics for each device required 
55 by the device-oriented protocol 1 4. 

[0032] Alternatively, a dictionary of device-specific information is contained on a dictionary server which is xt mat 
to the mapper 16. For example, the dictionary server may be attached to the field-bus 18. A dictionary server attached 
to th field-bus 18 is made by th mapper 1 6 to look to th applicatbn controller 1 2 as another device that conforms 



4 



EP0895145 A1 



to the device-oriented protcxx)! 1 4. As such, th application controller 1 2 updates the dictionary server attached to the 
field-bus 18 as new process control d vices becom availabi or are modified in terms of device^ecfflc information. 
[0033] In another alternative, the dictionary sen/ r is coupled to an external network (not shown) which is accessible 
by th application controller 1 2. t n such a case, the mapping processor 30 passes a dctionary request to th application 

s controller 12 which causes the application controller 12 to r triev th device-specrfic infonmation from th xtemal 
network server that contains the dictk>nary. The application controller 12 retrieves the information via the extemal 
network and passes the infomr^tion to the nr^ping processor 30 which writes it into the database 32. 
[0034] The configuration information contained in the device-oriented interface database 32 is readable by the ap- 
plication controller 1 2. The napping processor 30 receives a request for the infonmaton from the applicatwn controller 

10 1 2 through the device-oriented interface 34 arKj in turn reads the device-oriented database 32 and transfers the infor- 
matk)n to the application controller 12 through the device-oriented interface 34. In this way. the applicatkvi controller 
1 2 determines or 'discovers' what devices are attached, including the process control devrces 20-22 and the dictionary 
server if present. 

[0035] In the case where the device-oriented protocol 14 is the IEEE 1451 .2 standard, the applicatk>n controller 12 
IS initially transfers a request for the interface-specific information to the mapper 1 6. In response, the nnapping processor 
30 reads the interface-specific information from the database 32 and transfers it to the application controller 12 through 
the device-oriented interface 34. The application controller 1 2 examines the interface-specific infonmation to determine 
which channels are being used by the mapper 16. The applicatbn controller 12 then issues requests for the device- 
specific information for each of the indivkiual device channels being used. In response to each request, the mapping 
20 processor 30 reads the device-specific infomnation from the database 32 and provides it to the application controller 
1 2 through the device-oriented interface 34. 

[0036] For example, the device-specific information in the database 32 may inform the application controller 12 that 
the process control device 20 is a temperature sensor that provides units of Fahrenheit, When the mapping processor 
30 obtains a temperature measurement from the process control device 20 via the fieki-bus 18 it in turn provides the 
25 measurement data to the application controller 1 2 using the particular channel allocated to the process control device 
20 on the device-oriented interface 34. 

[0037] In additkjn to the channels of the device-oriented interface 34 whrch are allocated to the process control 
devices attached to the field-bus 18, the nnapping processor 30 alkx^ates two additional channels, referred to as dk:- 
tionary channels, for obtaining dictionary data from an external server through the application controller 12. A first of 

30 the dictionary channels, from the mapping processor 30 to the application controller 12, is used to request dictionary 
data from the extemal server The mapping processor 30 requests the dictionary cteta for a partk;ular process control 
device by transferring the device identifier for the particular process control device to the application controller through 
the first dictionary channel. The application controller 12 Interprets the devce kientifier received through the first dic- 
tionary channel as a request for dictionary data from an extemal server. After retrieving the requested dictkxiary data. 

35 In a manner described below, the application controller 1 2 transfers it to the mapping processor 30 through the second 
of the dictionary channels. 

[0038] The protocol of the particular field-bus 18 may support peer-to-peer communication between the process 
control devices 20-22. In prior art systems, the peer-to-peer communkation was accomplished by attaching a cc^fig- 
uration device to the field-bus 18. The configuration device woukJ include an interface for communication via the field- 
40 bus 18 and an applicatbn program that would setup the peer^o-peer communication by writing configuratbn informa- 
tion into the process control devbes 20-22. 

[0039] Unfortunately, the protocol for setting up such peer-to-peer communk:ation varies among the types of fiekJ- 
buses 18. For example, with one type of field-bus, the application program on the configuration device writes appropriate 
information to address tables contained within each of the process control devices 20-22. Such a technique causes 
45 the process control devk;e 20 to transfer its measurement data packets over the field-bus 18 with the address of the 
process control devbe 22 to accomplish peer-to-peer data transfer between the process control devices 20-22. Other 
types of field-buses use differing methods for setting up peer-to-peer transfers. 

[0040] The mapper 16 to provkJes applicatk)n controllers with a standardized interface for setting up peer4o-peer 
communicatk>n among the process control devices 20-22. The mapper processor 30 when building the database 32 

50 and allocating channels of the device-oriented interface 34 allocates channels from the apprication controller 1 2 to the 
mapper 16 for use in writing configuration information to the process control devices 20-22 for use peer-to-peer com- 
munk^tion. The appi ication controller 1 2 transfers the configuratk)n data through these channels of the device oriented 
interface 34 and the mapping processor 30 in turn writes the configuration data to the process control devices 20-22 
using the protocol of the field-bus 18. 

55 [0041] Table 1 shows the format of the interface-specific configuration information for an embodiment wherein the 
device-oriented protocol 14 is th proposed IEEE 1451 .2 standard. The mapping processor 30 buikJs the infornratbn 
in the fomnat shown into the d vtce-oriented interface database 32. 
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Table 1. 





Field# 


D scription 


#bytes 


£ 




TEDS V rsbn constant r lated information 






1 


Meta-TEDS Length 


4 




2 


IEEE PI 451 Standards Family Working Group Number 


1 




3 


TEDS Version Number 


1 


10 




Identification rebted informatbn 






4 


Globally Unique Identifier 


10 






Data stmcture related information 




IS 


5 


CHANNEL-ZERO Industry Calibration TEDS Extension Key 


1 




6 


CHANNEL-ZERO Industry Non-Volatile Data Fields Extension Key 


1 




7 


CHANNEL-ZERO Industry TEDS Extension Key 


1 




8 


CHANNEL-ZERO End Users' Application Specific TEDS Key 


1 


20 


9 


Number of Implemented Channels 


1 




10 


Worst-Case Channel Data Model Length 


1 




11 


Worst-Case Channel Data Repetitions 


2 


25 


12 


CHANNEL-ZERO writeable TEDS length 


4 






Timing related information 






13 


Worst-case channel update time 


4 


30 


14 


Global Write Setup Time 


4 


15 


Global Read Setup Time 


4 




16 


Worst-Case Channel Sampling Period 


4 




17 


Worst-Case Channel Warm Up Time 


4 


35 


18 


Command Response Time 


4 




19 


STIM Handshake Timing 


4 




20 


End-Of-Frame Detection Latency 


4 


40 


21 


TEDS Hold-Off Time 


4 


22 


Operational Hold-Off Time 


4 




23 


Maximum Data Rate 


4 






Channel grouping related information 




45 


24 


Channel Groupings Data Sub-bkx;k Length 


2 




25 


Number of Channel Groupings = G 


1 






Fields 26-28 repeated G times, once for each group 




50 


26 


Group Type 


1 


27 


Number of Group Members = N 


1 




28 


Member Channel Numbers List = M(N) 


N 






Data Integrity information 




55 


29 


Checksum for Meta-TEDS 


2 



[0042] Table 2 shows the format of the device-specific configuratkxi information for an embodiment wherein the 
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device-oriented protocol 14 is the propos d IEEE 1451 .2 stancterd. The mapping processor 30 builds th information 
In the format shown into th devic -oriented interface database 32 ither directly or by obtaining the inforn^tion from 
the devce dictionary 38 or a dictionary serv r. 

5 Table 2. 



Field# 


Description 


#bytes 




Data structure related information 




1 


Channel TEDS Length 


4 


2 


Calibration Key 


1 


3 


Channel Industry Calibration TEDS Extension Key 


1 


4 


Channel Industry Non-Votatile Data Fields Extension Key 


1 


5 


Channel Industry TEDS Extension Key 


1 


6 


Channel End Users' Application Specific TEDS Key 


1 


7 


Channel Writeable TEDS Length 


4 




Transducer related information 




8 


Channel Type Key 


1 


9 


Physical Units 


10 


10 


Lower Range Limit 


4 


11 


Upper Ftange Limit 


4 


12 


Worst-Case Uncertainty 


4 


13 


Self Test Key 


1 




Data converter related information 




14 


Channel Data Model 


1 


15 


Channel Data Model Length 


1 


16 


Channel Model Significant Bits 


2 


17 


Channel Data Repetitions 


2 


18 


Series Origin 


4 


19 


Series Increment 


4 


20 


Series Units 


10 




Timing related infornrtation 




21 


Channel Update Time 


4 


22 


Channel Write Setup Time 


4 


23 


Channel Read Setup Time 


4 


24 


Channel Sampling Period 


4 


25 


Channel Warm Up Time 


4 


26 


Channel Aggregated Hold Off Time 


4 


27 


Timing Correction 


4 


28 


Trigger Accuracy 


4 




Event Sequence Options Field 




29 


Event Sequence Options 


1 
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Table 2. (continued) 



Field# 


Description 


#bytes 


Data Integrity tnfoimation 


30 


Checksum for Channel TEDS 


2 



[0043] Table 3 shows the format of the device-specific configuration information which is related to the calibration 
characteristics of process control devices for an embodiment wherein the device-oriented protocol 1 4 is the proposed 
10 IEEE 1 451 .2 standard. The mapping processor 30 builds the information in the format shown into the device-oriented 
interface database 32 either directly or by obtaining the information from the device dictionary 38 or a dictionary server. 



Table 3. 



Field# 


Description 


#bytes 




Data structure related information 




1 


Calibration TEDS Length 


4 




Calibration relating information 




2 


Last Calibration Date-Time 


4 


3 


Calibration Interval 


4 


4 


Number of Correction Input Channels = n 


1 


5 


Correction Input Channel List 


n 


6 


Correction Input Channel Key List 


n 


7 


Channel Degree List = D(k) 


n 


8 


Number of Segments List = \ 


n 


9 


Segment Boundary Values Table 


4*(Ni+N2+...N„+n) 


10 


Segment Offset Values Table 


4*(Ni+N2+...N,) 


11 


Multinomial coefficient 


4*Ni*N2V.N„* 

[D(1)+inD(2)+1] 

*..lD(n)+1l 




Data integrity information 




12 


Checksum for Calibratk3n TEDS 


2 



40 [0044] Figure 3 illustrates an example process control system 40 that enables process control applications executing 
on a set of application controllers 60-62 to access process control device adapted to differing f tekJ-bus protocols through 
a standard interface. The three sets of process control devices 90-91 , 100, and 110-112 shown are adapted to a set 
of differing field-buses 80-82, respectively. The field-buses 80-82 have differing predefined protocols for communrcatwn 
with their respective process control devk;es. In this example, the protocols of the field-buses 80-82 are the Profi-Bus 

45 protocol, the SDS bus protocol, and the LonTalk bus protocol, respectively. 

[0045] A set of mappers 70-72 enable the applrcation controllers 60-62 to access the process control devices attached 
to the field-buses 80-82 through a standard devrce-oriented interface without regard to the protocols of the fieki-buses 
80-82. In this example, the nr^pper 70 maps between the Profi-Bus protocol of the field-bus 80 and the devce-oriented 
protocol 14 of the application controller 60. Similarly, the mappers 71 and 72 map between the SDS and LonTalk 

so protocols of the field-buses 81 and 82, respectively, and the device-oriented protocol 14 of the applicatbn controllers 
61 and 62. 

[0046] The process control system 40 includes a host processor 50 whbh is in communk^tion with the application 
controllers 60-62 via a communk^ation network 52. The communication network 52 represents any standard conomu- 
nicatbn network suitable for communk:ation among a variety of types of computers such as an Ethernet network. The 
55 host processor 50 uses the communk^ation network 52 to monitor the status of all the devices and applications in the 
process control system 40. 

[0047] A dictionary server 1 1 4 coupled to the field-bus 82 contains the device-specific information pertaining to the 
process control devices 110-112 that enables the mapping processor in the mapper 72 to build the d viceoriented 
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interface databas in the mapper 72. The mapper 72 reads the dictionary serv r 114 using the LonTalk protocol. In 
addition, the mapp r 72 makes th dictionary server 114 appear to the application controller 62 as a devce that con- 
forms to the devc -ori nted protocol 1 4. As such, the application controller 62 can write dictionary data to the dictionary 
server 114 using th d vice-oriented protocol 14. 
5 [0048] A dctbnary server 54 coupled to th communicatbn network 54 contains a dictionary of devk; -specific in- 
formatk)n that enables the mapping processors in the mappers 70-71 to buiW device specific information in their re- 
spective device-oriented interface databases. The mappers 70-71 obtain the device-specific informatk>n for partk:utar 
process control devices with the aid of the applk:atbn controllers 60-61 . 

[0049] For example, the mapper 71 and the applk:ation controller 61 make use of the two dctionary channels on 
10 their device-oriented interface to obtain dictionary data from the dictkxtary server 54. The applk:ation controller 61 
includes circuitry and software for communicatk>n over the network 52. The applk:ation controller 61 in response to a 
request for dictbnary data from the mapper 71 via the first dkitbnary channel retrieves the requested information from 
the dictkxiary server 54 and transfers the information to the mapper 71 through the second dictbnary channel. 
[0050] The disclosures in United States patent applicatbn no. 08/904,364, from which this application claims priority 
IS and in the abstract accompanying this application are incorporated herein by reference 



Claims 

20 1 . Apparatus for providing a standard interface to a process control device (20) which is adapted to a predetermined 
field-bus protocol of a field-bus (18), comprising: 

means for obtaining a set of infomnatbn pertaining to the process control device (20) wherein the infornnation 
describes the process control device (20) according to a predetermined devrce-oriented protocol (1 4) that 
25 corresponds to the standard interface; 

means for enabling a process control applk:atk)n to access the information using the predetermined device- 
oriented protocol (14). 

2. Apparatus as in claim 1 , wherein the obtaining means is operable to obtain informatbn directly from the process 
30 control devk^e (20) via the field-bus (1 8) using the predetermined field-bus protocol or to obtain the infonrration 

from a dk:tk>nary (38) that contains multiple sets of informatbn pertaining to differing types of process control de- 
vices. 

3. Apparatus as in claim 2, wherein the dictkxiary (38) is stored on a dKtk>nary server (114) which is accessible via 
35 the fiekJ-bus (18) or which is accessible via an external network (52). 

4. Apparatus as in claim 1 , 2 or 3, comprising means for using the standard interface to transfer a set of peer4o-peer 
configuratbn infomriation into the process control device (20). 

40 5. Apparatus as in any preceding claim, comprising: 

means for generating a set of interface-related informatbn that specifies at least one channel of the standard 
interface to be used for communrcation with the process control device (20) according to a predetermined 
device-oriented protocol (14); 

45 means for enabling the process control application to access the interiace-related informatk>n using a prede- 

termined device-oriented protocol (14). 

6. Apparatus as in claim 5, wherein the channel is used by the prcx:ess control application to read or to write data 
from the process control device. 

50 

7. Apparatus as in claim 5 or 6, wherein the interface-related information specifies a set of dictionary channels to be 
used for obtaining information pertaining to the process control devbe (20) from an external dictionary server (54). 

8. A process control system comprising: 

55 

a s t of process control devfces (20) coupled to a field-bus (18), wherein each process control devic (20) is 
adapted to a predetemiined protocol of the field-bus (18); and 

a mapp r (1 6) operabi to enable an applicatbn controller (1 2) to access the process control devices (20) as 
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if the process control devices (20) conformed to a standard interf ac having a predetermined device-orientated 
protocol (14). 

9. A process control system as in claim 8, wher in the mapp r (16) compris s: 

a ReW-bus interface (36) for enabling access to the process control devices (20) via the field-bus (18) using 
the predetermined protocol otthe field-bus (18); 

a device oriented interface (34) for enabling communication with the application controller (12) using the pre- 
determined device-oriented protocol (14); 

a database (32) for holding a set of intomriation pertaining to the process control devices (20) which describes 
the process control devices (20) in terms ofthe predetermined device oriented protocol (14); 
a mapping processor (30) for building the infonmation in the database (32) an6 for enabling access to the 
information by the application controller (12) via the device-oriented interface. 

10. A process control system as in claim 9, wherein the mapper (16) comprises a device dictionary (38) containing 
multiple sets of information pertaining to differing types of process control devices from which the mapping proc- 
essor (30) builds the database (32). 

11. A process control system as in claim 9 or 10 comprising a dictionary server (114) coupled to the field-bus (18) or 
to an external network (52), wherein the dictionary sewer (114) contains multiple sets of information pertaining to 
differing types of process control devices from which the mapping processor (30) builds the database (32). 

12. A process control system as in claim 9, 1 0 or 1 1 , wherein the mapper (1 6) is operable to generate a set of interface- 
related information that specifies at least one channel ofthe standard interface to be used for communication with 
each process control device (20) according to a predetermined device-oriented protocol (1 4) and to enable the 
application controller (12) to access the interface-related information using the predetermined device-oriented 
protocol (14). 

13. A process control system as in claim 12, wherein one of the channels is used by the application controller (12) to 
read, to write data or to write pecr-to-peer configuration data from the con-esponding process device (20). 

14. A process control system as in claim 12 or 13, wherein the interface-related infornDation is operable to specify a 
set of dictionary channels to be used by the application controller (12) and the mapper (16) to communicate infor- 
mation pertaining to the process control device (20) obtained from an exlemal dictionary sender (54). 
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FIG. 2 
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